The present invention relates to methods and apparatus for facilitating the detection of suspect software objects and/or suspect object signatures.
Such software objects may include, but are not limited to, application code, operating systems and associated components (e.g. dynamic link librariesxe2x80x94DLL""s), Basic Input/Output Structures (BIOS), Java Virtual Machines (JVM), Java applications and applets, etc., residing in television set-top terminals. These objects (and/or their associated signatures) can be rendered xe2x80x9csuspectxe2x80x9d by tampering, which generally occurs when a xe2x80x9cpiratexe2x80x9d or xe2x80x9chackerxe2x80x9d attempts to defeat the security of the system over which the objects are communicated. An object or signature that is suspect has questionable validity and cannot be trusted.
As digital set-top terminals for cable and satellite television (e.g., the DCT5000+ provided for cable television systems by General Instrument Corporation of Horsham, Pa., U.S.A.) incorporate the capability to download different operating systems (e.g., Microsoft""s WinCE), DLL""s, JVM""s, multiple system cable operators (MSO""s) need a mechanism that will allow them to maintain control of the features, applications, and software objects in general that run or are utilized within these set-top terminals. More specifically, MSO""s want the ability to access control services and associated usage of software objects in set-top terminals.
One known attempt to address the authenticity of code objects for the PC environment is Microsoft""s xe2x80x9cAuthenticodexe2x80x9d capability. This product enables software vendors to acquire a digital signature for published executable code. Authenticode provides a digital signature with only one signer; the code is signed with Microsoft""s private key (which is not published) and is verified with Microsoft""s public key, which is bundled into the Authenticode verification code in the operating system. However, while Authenticode provides digital signature protection for executable code, it does not provide any means of determining access requirements for the executable code for access control purposes (and revenue generation purposes), and it is applicable only to executable code.
A second known attempt to address control of Java applets is xe2x80x9cJava Securityxe2x80x9d which is intended to prevent applets from inspecting or changing files on a client system and from using network connections to circumvent file protections or data privacy measures. However, as is the case with Authenticode, Java security does not offer authentication of any software object unless it is Java based, nor does it offer the association with access requirements for access control and revenue generation purposes.
Although each of the products described above attempt to address protection and control of software objects against unauthorized utilization in a PC environment, they do not fully address the issues associated with authorization, authentication and access control, and thus, do not provide an optimal solution that meets MSO requirements.
As set-top terminals assume a computing environment for entertainment purposes by utilizing downloadable software objects such as operating systems, libraries, Java Virtual Machines, applications, applets, etc., it becomes extremely critical to protect and control the software object to guard against unauthorized utilization by a given set-top terminal. Not only does the identity of each software object require authentication but also, its utilization has to be subject to MSO control via authorization permissions along with control of which set-top terminal resources a given software object may use. These measures complement those of object validation and verification and ensure that software objects that have not been authenticated are not utilized. To the extent that these measures are utilized, the set-top terminal is no longer subject to problems associated with objects that have failed to follow the security design rules, or worse yet, those which may be contaminated with a virus that is meant to cause harm to the MSO""s network and associated set-top terminals.
Commonly assigned, copending U.S. patent application Ser. No. 09/257,274 filed Feb. 24, 1999 discloses methods and apparatus for creating a signature and associating the signature with a software object that is to be downloaded and used in a set-top terminal. A conditional access subsystem in the set-top terminal is provided with the appropriate routines to examine the validity of the signature by comparing (i) the signature sent from, e.g., a television system headend to (ii) a signature generated locally at the set-top once the object has been downloaded. In the event a check failed, there was no way of determining whether (a) the downloaded object was suspect or (b) the signature with the message that delivered it was suspect.
It would be advantageous to provide a scheme for determining, when an authentication operation fails in a set-top terminal, whether the object being authenticated or the received signature has been suspect. The present invention provides methods and apparatus having the aforementioned and other advantages.
In accordance with the invention, a method is provided for analyzing a failed software object authentication to determine whether the software object or a signature for the software object is suspect. A transmitted software object signature value s is extracted from a message m(s) carrying the signature value s. An object signature value sxe2x80x2 is separately calculated from the software object. A value v equal to the result of a secret signature transformation function f(s), operating on signature s, is extracted from the software object. A signature value sxe2x80x3 is generated by applying the inverse f(s)xe2x88x921 of the signature transformation function f(s) to the extracted value v. The value of the signature sent in m(s) is compared with the calculated signature value sxe2x80x2. If the two are equal,then the authentication has been validated. If not, the following additional steps are taken. The signature value sxe2x80x3 is compared to sxe2x80x2. If the two are equal then the likelihood is that the signature value s in the sent message m(s) was suspect. If the value of sxe2x80x3 equals the sent signature value s in m(s) then the likelihood is that the object itself is suspect. In other words the signature value in message m(s) is designated as suspect if sxe2x80x3=sxe2x80x2. Conversely, the software object is designated as suspect if sxe2x80x3=s.
In one particular embodiment, first and second copies of the value v are carried at different locations of the software object for redundancy. Each, of the copies is extracted from the software object. The signature value sxe2x80x3 corresponds to the first copy of the value v. A second signature value, s2xe2x80x3 is generated for the second copy of the value v. The method of this embodiment includes the further step of comparing the signature value s2xe2x80x3 to at least one of the transmitted object signature values s and the calculated object signature value sxe2x80x2. The signature value in message m(s) is designated as suspect if s2xe2x80x3 =sxe2x80x2. The software object is designated as suspect if s2=s. Both the signature associated with the software object and the message m(s) can be designated as suspect if s2xe2x80x3 does not equal either sxe2x80x2 or s, although it should be appreciated that this is the least likely case and is not as deterministic since. s2xe2x80x3 may be suspect as well. In such an embodiment, the value v can, for example, be appended at the beginning of the software object and at the end of the software object, although other locations may be equally satisfactory.
Alternate embodiments and corresponding apparatus is also provided.